A storage is computer-readable media capable of storing data in blocks. Storages face a myriad of threats to the data they store and to their smooth and continuous operation. In order to mitigate these threats, a backup of the data in a storage may be created to represent the state of the source storage at a particular point in time and to enable the restoration of the data at some future time. Such a restoration may become desirable, for example, if the storage experiences corruption of its stored data, if the storage becomes unavailable, or if a user wishes to create a second identical storage.
A storage is typically logically divided into a finite number of fixed-length blocks. A storage also typically includes a file system which tracks the locations of the blocks that are allocated to each file that is stored in the storage. The file system also tracks the blocks that are not allocated to any file. The file system generally tracks allocated and unallocated blocks using specialized data structures, referred to as file system metadata. File system metadata is also stored in designated blocks in the storage.
Various techniques exist for backing up a source storage. One common technique involves backing up individual files stored in the source storage on a per-file basis. Another common technique for backing up a source storage ignores the locations of individual files stored in the source storage and instead simply backs up all allocated blocks stored in the source storage. This technique is often referred to as image backup because the backup generally contains or represents an image, or copy, of the entire allocated contents of the source storage. Using this approach, individual allocated blocks are backed up if they have been modified since the previous backup. Because image backup backs up all allocated blocks of the source storage, image backup backs up both the blocks that make up the files stored in the source storage as well as the blocks that make up the file system metadata. Also, because image backup backs up all allocated blocks rather than individual files, this approach does not necessarily need to be aware of the file system metadata or the files stored in the source storage, beyond utilizing minimal knowledge of the file system metadata in order to only back up allocated blocks since unallocated blocks are not generally backed up.
One way to accomplish image backup is using a snapshot, which enables the state of the source storage at a particular point in time to be captured without interrupting other processes, thus avoiding downtime of the source storage. Many snapshots employ a “copy on write” methodology which requires that every write command, received by the source storage while a snapshot is active, be delayed until the original data block at the location targeted by the write command is copied for safekeeping to a new location. In this manner, the copied original blocks stored in the new location, as well as the unchanged original blocks stored in the source storage, are “frozen” at the snapshot time and define the “snapshot,” which can then be employed in the creation of an image backup of the source storage. Then, once the image backup has been created, the snapshot can be deactivated and the data blocks that were copied as part of the snapshot can be discarded.
A source storage may be initially backed up using an image backup operation to create a full image backup and then, in successive image backup operations, incremental image backups of the source storage may be created. A new incremental image backup may include only those blocks of the source storage that were changed between the snapshot time of the most recent image backup (whether full or incremental) and the snapshot time of the new incremental image backup. In order to easily back up only changed blocks during the creation of an incremental image backup, it can be useful to incrementally track which blocks are changed between snapshot times instead of determining which blocks are changed by performing a costly full compare of every block in the source storage with corresponding blocks in a full image backup and any incremental image backups that were previously created.
One common problem that is encountered during successive image backup operations is the difficulty of reliably tracking incremental changes between snapshot times. For example, incremental changes are typically tracked in a data structure stored in volatile memory using a driver. Over time, reliable tracking of incremental changes may require an update to the driver, which typically involves unloading the driver during the shutdown of an operating system and the subsequent loading of an updated driver upon rebooting the operating system, which may ensure that no blocks are changed by the operating system between the unloading of the driver and the loading of the updated driver. While this shutdown and reboot procedure may be a reliable way to update a driver while reliably tracking incremental changes, it has the distinct disadvantage of forcing an otherwise unnecessary reboot of the operating system, as well as the downtime of the operating system between the shutdown and the reboot, which for certain operating systems, such as those running on critical servers, may be unacceptable.
The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one example technology area where some embodiments described herein may be practiced.